星期一早上剛進公司,同事就跑來說:「檔案傳不上去了,系統是不是壞了?」我登入伺服器檢查,才發現磁碟早在週末就已經塞滿。那時公司只有幾台 Windows、Ubuntu、檔案伺服器與測試機,平常都是想到才逐台登入看看。這次狀況讓我開始思考:能不能在同事發現以前,就先知道哪台機器出問題?
所以第一版沒有急著做很炫的圖表,而是先完成五件事:看得到 Windows 與 Ubuntu 的狀態、集中看 CPU/記憶體/磁碟、有異常能通知、知道容量是否突然增加,還能直接開遠端工具。
我學到的是,先問清楚「發現問題後誰要做什麼」,比先決定畫面要放哪些數字更重要。
HardwareMonitor 儀表板與主機容量概覽
def level_for(disk, host):
used = float(disk.get("used_percent", 0))
if used >= float(host.get("critical_percent", 90)):
return "critical"
if used >= float(host.get("warning_percent", 80)):
return "warning"
return "normal"
重點不是三個狀態名稱,而是讓每個狀態都能對應後續處理行動。
實務上還要另外區分「沒有資料」與真正的 0%,否則離線主機可能被誤判為正常。
host = {"warning_percent": 80, "critical_percent": 90}
for used in (65, 82, 93):
disk = {"mount": "C:", "used_percent": used}
print(used, level_for(disk, host))
# 65 normal
# 82 warning
# 93 critical
這個例子把需求轉成可直接驗證的輸入與輸出,也能作為後續單元測試的基礎。
最早的版本只記錄主機是否連得上,結果檔案服務明明因磁碟滿載而無法寫入,畫面仍顯示「在線」。這不是連線 Bug,而是需求定義得太窄。我重新拆解「正常」的意思,把連線、CPU、記憶體、磁碟容量與資料更新時間分開呈現,避免用單一綠燈掩蓋真正問題。這次修正也讓我明白,很多 Bug 並不是程式寫錯,而是我們一開始問錯了問題。
今天最大的收穫,是監控工具要先回答「出問題時誰要做什麼」,再決定顯示哪些數字。下一篇會把需求整理成小團隊能維護、也保留成長空間的架構。
